When you render a polygon using OpenGL, how the polygon is actually drawn depends on the currently enabled OpenGL modes and their associated parameters. A polygon is rendered differently depending on how lighting, texturing, blending, antialiasing, depth testing, and a host of other OpenGL modes are configured. It is useful to think of sets of rendering modes and their associated parameters as rendering paths through the OpenGL implementation. By enabling rendering modes and selecting their parameters, you are logically choosing a rendering path through OpenGL's state machine. The performance of actual rendering operations along a specific rendering path depends on how well that path is optimized and supported in hardware by your specific OpenGL implementation.
The GTXRD taxonomy is useful for obtaining a high-level, coarse view of the types of operations that are potentially supported in hardware.
In practice, a system considered a GT-XRD architecture may incompletely support OpenGL's full transformation and rasterization functionality in hardware. For example, a GT-XRD system may not have support for texture mapping in its rasterization hardware. This means any rendering path with texturing enabled will ``fall back'' to a software path. Falling back to software means tasks in the transformation stage that could potentially have been done in hardware without texturing enabled typically also must to fall back to software. It is important to realize that having a feature supported ``in hardware'' does not assure that the hardware can be used on every rendering path.
Even when rendering paths for two different sets of modes are supported via specialized hardware, you are still very likely to find that one path is faster than another. For example, when OpenGL lighting is enabled, enabling a single light is quite likely to be faster than enabling all eight possible lights. And even though depth testing is supported in hardware, a rendering path with depth testing disabled is likely to run faster than one without depth testing.
At a high-level, the GTXRD nomenclature is a good way to classify broadly the extent of hardware acceleration for a graphics hardware architecture. At the level of a specific application's graphics usage, however, it is better to consider the actual rendering paths exercised by the application and decide if a given OpenGL implementation sufficiently optimizes those paths and whether the available hardware is effectively utilized.
When evaluating an OpenGL implementation for a specific application, find out what graphics functionality is implemented in hardware and what is implemented in software. Be careful not to expect every OpenGL feature to be supported in hardware. Instead, match your choice of system to your application performance demands and cost constraints. Be particularly careful about being misled by ``standard'' benchmarks since they may measure graphics performance for a rendering path that is not particularly important to your application. There is no substitute for your own benchmarking of the particular rendering paths you care about most.
Considering the performance of specific paths without the context of a specific application is difficult when evaluating OpenGL performance in the overall selection of a graphics workstation. Instead, let general considerations guide you like the GTXRD classification of the machine and general questions like whether a depth buffer is supported in hardware or what type of texture mapping hardware is provided (assuming these capabilities are broadly desirable for the system you are selecting). Benchmarks can be useful, but be wary because sometimes benchmarks are selected to show off particularly efficient rendering paths, and benchmarks more often demonstrate maximum performance as opposed to typical performance. More on benchmarks later.
The remainder of this article describes the stages of the OpenGL graphics pipeline in more detail and considers window system features for enhancing OpenGL's window system integration. The last section takes a more global view of graphics systems and considers bottlenecks in and between different stages that can undermine overall graphics performance.
Figure 2: Overlay planes used to annotate a complex underlying image.